运维思索：系统监控体系
点击上方蓝色字体，关注我们
读完需 6 分钟
速读需 3 分钟
各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。
因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。
本次分享的是确立一套运维监控体系，构建可持续成长的监控平台。
系统监控现状及问题
1.如何监控？
硬件、基础状态、应用、业务，监控对象多而且杂，如何能够全部覆盖？
企业内部的各种监控工具，我们应该如何管理？
监控工具之间的信息孤岛如何处理？
2.如何告警？
告警太多，如何沉淀有效告警？
告警泛滥，如何进行收敛，避免告警的狂轰滥炸？
3.如何处理？
告警处理无记录，和企业运维流程脱节，怎样形成知识沉淀？-----所谓的知识库，线下整理不及时，增加工作负担。
告警处理纯靠手动，每个月都在重复处理相同故障，如何避免？-----手动处理效率不高，牵扯太多的精力。
以上问题是在建设监控系统时面临的一些问题，以前我总是想用一个监控产品来实现所有的需求，避免我们在多个产品间来回切换，看来有点舍本逐末。
平台化监控思路转变
首先，我们先从监控的本质出发：监控系统的目的是为了及时发现问题，解决问题，直至预测问题，不是为了整合系统。
其次，随着公司技术栈的不断升级，业务系统的架构也在不断演进，而原来传统监控可能就不能够满足监控需求。此时就需要不断补充监控手段，例如Grafana、Prometheus、ELK，实现图形化监控、容器监控、日志监控。因此监控平台一定是多种监控产品并存，而运维需要构建可持续成长的监控平台。
最后，在认清以上监控治理的现状后，我们需要实现监控建设的思路转变：由产品化思路向平台化思路转变。即：由要找一个大而全的监控产品，囊括全部的监控诉求转变为需要一个具备功能生长性的监控平台，来承载核心监控诉求，并能统一集成外部的各种监控产品，服务于业务监控的目标。
PaaS属性
构建功能可持续成长的监控平台，关键在于监控平台需要具备paas属性：
1
监控iPaaS层
监控平台层，负责提供面向各类监控对象的基本的监控采集、存储、分析和告警的能力和工具；同时需要提供paas集成能力，能够对接和集成外部监控工具和系统。
2
监控aPaaS层
监控场景工具层，通过调用平台层的监控能力和监控工具，面向具体的应用和业务，提供组装式的、复合的监控场景工具，例如：统一告警中心、监控可视化、故障自愈等。
总结大体布局如下：
从这套监控架构来看，相信很多小伙伴都已经实现到了iPaaS（监控平台层）级别的监控，往往忽视了aPaaS（监控场景层）的多样性需求，如统一告警中心、故障自愈等的需求。而我们建立监控系统就是通过场景去发现问题、解决问题、甚至是预测问题。
虽然以上统一监控完成了监控由产品到平台的转变，也同样存在以下优缺点：
集成不同的监控工具，一定程度上实现了监控数据之前的共享和融合；
业务和应用无法有效关联，导致告警在一定程度上是脱离业务的，需要运维人员自行脑图总结；
由于不同工具的接入，平台层和场景层如何联动，需要运维人员统一API接入；
看到这，小伙伴会想：为什么问题都是会不期而至呢？因为这些就是我们平时会忽略的细节问题。如果我们能集中资源从细节入手，那么我们可能就会得到意想不到的收获！
总结
了解过蓝鲸的小伙伴，可能对以上内容比较熟悉，但重点是我们如何站在巨人的肩膀上来看清我们的不足，从什么角度去思考问题。
以上的平台化监控架构可以为我们构建系统监控体系提供了思路，剩下的就是我们如何从细节性问题入手，利用技术手段去解决问题了。